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1  Introduction  -  The  What,  Why,  and  How  of  DSEA&A 

The  Air  Force  Life  Cycle  Management  Center  (AFLCMC)  Hanscom  Operating  Location 
(Hanscom-OL)  (formerly  known  as  Electronic  Systems  Center  or  ESC)  implemented  a 
methodology  called  Domain  Systems  Engineering,  Architecting  and  Analysis  (DSEA&A)  to 
enable  the  identification  and  resolution  of  domain-level  problems  or  opportunities  related  to 
affordability,  efficiency,  and  effectiveness  (AE&E).  The  goal  of  DSEA&A,  also  referred  to  as 
domain  analytics  (DA),  is  to  consider  and  assess  a  set  of  potential  solutions  to  resolve  problems 
identified  by  one  or  more  domain  stakeholders.  The  scope  of  a  DSEA&A  effort  can  be  wholly 
contained  within  a  Program  Executive  Officer’s  (PEO)  portfolio  or  can  span  multiple  PEOs’ 
portfolios.  DSEA&A  was  developed  in  response  to  AF  higher  headquarters’  desires  to  identify 
and  deliver  cross-cutting,  affordable  solutions  in  a  timely  manner. 

1 .1  Purpose  of  this  Document 

This  document  provides  a  high-level  introduction  to  DSEA&A.  It  highlights  one  way  to  do 
DSEA&A  based  on  lessons  learned  in  applying  these  concepts  to  acquisitions  at  the  Hanscom 
Operating  Location  (Hanscom-OL)  of  the  AF  LCMC.  This  is  a  set  of  guidelines  and  not  a 
prescription.  DSEA&A  builds  on  traditional  systems  engineering,  architecture,  and  analysis 
methodologies.  Individual  DSEA&A  activities  must  be  considered  relative  to  the  domain  and 
problem  at  hand  and  should  be  tailored  as  needed. 

1.2  Audience 

This  document  is  targeted  primarily  to  DSEA&A  practitioners  aka  “domain  engineers.”  It  is  also 
suitable  as  background  information  for  a  wide  range  of  audiences  including  leadership,  policy 
makers,  users,  and  acquisition  personnel.  We  assume  that  you  are  new  to  DSEA&A  but  have 
some  exposure  to  traditional  systems  engineering. 

1 .3  Scope  of  this  Document 

This  document  addresses  only  the  additional  effort  required  to  do  DSEA&A.  It  does  not  address 
how  to  do  traditional  systems  engineering,  basic  architecting  and  analysis,  system 
implementation,  program  management,  etc.  The  reader  is  presumed  to  have  a  basic 
understanding  of  these  related  areas. 
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2  Essential  Questions 

2.1  What  is  a  Domain? 

DSEA&A,  as  its  name  implies,  is  focused  on  the  concept  of  a  “domain.”  A  domain  is  a  flexible 
concept.  We  often  hear  about  “the  air  domain,”  “the  ISR  domain,”  or  “the  cyber  domain,”  but 
there  are  many  types  of  domains. 

Merriam-Webster  [10]  defines  “domain”  as: 


2:  a  territory  over  which  dominion  is  exercised 

3:  a  region  distinctively  marked  by  some  physical  feature  <the  domain  of  rushing 
streams,  tall  trees,  and  lakes> 

4:  a  sphere  of  knowledge,  influence,  or  activity  <the  domain  of  art> 


The  term  domain,  as  used  herein,  refers  to  a  bounded  part  of  some  problem  space  having  an 
identifiable  controlling  individual  or  group  of  individuals  authorized  to  make  decisions. 

For  the  purposes  of  DSEA&A: 

•  domains  can  be  based  on: 

o  a  common  purpose 

o  mission  area  characteristics  (e.g.,  C2,  ISR,  cyber,  business  operations) 
o  geo-spatial  considerations  (e.g.,  land,  sea,  air,  space) 
o  common  functional  characteristics  (e.g.,  communications  and  networking 
infrastructure,  sensor  technology) 

•  may  encompass  a  set  of  common  capabilities1  and  (for  information-based  domains) 
common  data 

•  are  generally  supported  by  many  acquisition  programs  across  multiple  acquisition 
organizations  (and  a  single  acquisition  program  might  support  multiple  domains)2 

•  can  be  “big”  or  “small”  (i.e.,  vary  widely  in  breadth  and  depth) 

•  can  be  decomposed  into  “sub-domains”  and  can  conversely  be  part  of  a  larger  domain 
(i.e.,  sub-domains  may  inherit  certain  attributes  of  their  parent  domain) 

•  can  cross  other  domains  (e.g.,  the  “air  domain”  may  include  some,  but  not  all,  elements 
of  the  ISR  domain;  the  intersection  might  be  called  “the  air  ISR  domain”  and  would  by 
definition  be  a  sub-domain  of  each) 


1  A  capability  includes  multiple  aspects  to  include  people,  processes,  and  tools  (materiel)  and  is  focused  on  achieving  a 
measurable  effect. 

2  A  domain  may  be  scoped  so  as  to  be  wholly  addressed  by  a  single  acquisition  program  in  which  case  DSEA&A  is  essentially 
traditional  SE  applied  to  the  scope  of  the  domain  versus  the  system  being  acquired. 
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•  can  be  associated  with  zero,  one,  or  more  Systems  of  Systems  (SoSs)  [9]  (similarly,  a 
given  SoS  may  span  multiple  domains) 

When  scoping  a  domain,  you  need  to  identify  a  “domain  authority”  -  i.e.,  some  individual  or 
group  who  can  make  decisions  about  relevant  aspects  of  the  domain  (e.g.,  planning,  acquisition, 
operations)  and  who  has  some  degree  of  accountability  for  those  aspects.  The  domain  authority 
may  be,  for  example,  a  PEO  or  Service  Acquisition  Executive  or  a  similar  representative  from 
the  requirements  or  strategic  planning  community.  Identifying  a  domain  authority  can  be 
especially  challenging  in  cases  where  the  domain  is  large  and/or  cross-cutting  and  several  PEOs 
or  Core  Function  Lead  Integrators  (CFLIs)  may  be  involved  in  a  decision. 

Some  domains  display  a  mix  of  defining  characteristics.  For  example,  “cyber”  can  be  thought  of 
as  both  functional  and  mission-oriented  in  nature. 

2.2  What  is  Domain  Systems  Engineering  Architecting  &  Analysis 
(DSEA&A)? 


DSEA&A  is  an  attempt  to  address  one  or  more  problems  associated  with  a  domain  -  or, 
alternatively,  to  achieve  some  desired  outcome3.  DSEA&A  efforts  are  typically  exploratory, 
agile,  and  time-bounded  in  nature.  They  explore  both  the  problem  space  and  the  solution  space, 
attempt  to  adjust  to  the  findings  that  result  from  this  exploration,  and  follow  an  incremental 
approach. 

DSEA&A  is  a  mix  of  synthesis  and  analysis  activities.  The  domain  engineer  creates  (synthesize) 
a  high-level  representation  (an  architectural  model4)  of  the  domain  to  include  both  the  problem 
space  and  the  solution  space.  They  refine  this  representation  by  analyzing  the  problem  space  and 
iterating  potential  solutions  within  the  context  of  a  tradespace5.  They  identify  issues,  risks,  and 
opportunities  in  the  existing  architectures,  designs,  or  CONOPS  associated  with  the  domain6  (to 
include  those  pertaining  to  related  programs).  Finally,  they  assess  each  potential  solution,  based 
on  pre-defined  assessment  criteria.  This  leads  to  information  that  decision  makers  can  use  in 
choosing  a  specific  solution. 

The  representation  of  the  domain  is  key.  The  representation  should  highlight  key  aspects  and 
support  effective  situational  awareness  as  well  as  exploration  and  analysis  of  current  (“as-is”) 
and  alternative  future  (“to-be”)  states.  The  DoD  Architecture  Framework  (DoDAF)  [5]  provides 
a  degree  of  rigor  for  developing  domain  architectures  (models),  but  we  want  to  stress  some 
important  points: 


3  DSEA&A  efforts  should  be  focused  on  achieving  some  desired  outcome  associated  with  the  domain.  An  outcome  is  a  change 
in  the  state  of  the  domain.  One  kind  of  outcome  is  the  resolution  of  some  known  issue  or  problem,  but  outcome-directed 
thinking  is  a  mindset  that  focuses  on  achieving  goals  vs  (just;)  fixing  problems.  See  [8]  for  a  discussion  of  the  difference 
between  outcome-directed  thinking  and  problem-directed  thinking. 

4  DSEA&A  can  be  thought  of  as  supporting  Model-Based  Systems  Engineering  (MBSE)  [6] 

5  A  tradespace  identifies  the  range  of  solution  parameters  that  can  be  varied  to  achieve  various  effects.  This  can  include  various 
aspects  of  a  materiel  solution  as  well  as  other  DOTMLPF  aspects. 

6  Such  issues,  risks,  and  opportunities  may  only  be  apparent  when  viewed  from  the  scope  of  the  domain. 
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•  The  architecture  must  support  the  analysis  (not  just  be  a  set  of  visualizations). 

•  The  architecture  is  the  underlying  structured  data,  e.g.,  assets,  missions,  threats, 
information  exchanges,  supporting  systems  and  their  relationships,  and  not  the 
visualizations  of  that  data.  Thus,  it  is  more  important  to  have  and  understand  the 
architectural  data  than  it  is  to  formalize  the  data  in  specific  views. 

•  The  architecture  should  reflect  the  actual  current  situation  rather  than  an  idealized 
situation  that  might,  for  example,  better  align  to  current  vision  or  policy. 

•  The  architecture  is  a  model  of  both  the  problem  (requirements  space)  and  potential 
solution(s)  (technology  space). 

•  The  architecture  reflects  the  domain  and  is  scoped  to  a  specific  purpose  (desired  outcome 
or  problem  resolution).  It  is  generally  not  as  detailed  as  a  typical  program-level 
architecture. 

•  The  to-be  architecture  should  support  anticipated  operational  scenarios. 
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Figure  1  -  Domain  Outcomes  Supported  by  DSEA&A 

Figure  1  depicts  the  context  for  DSEA&A  at  a  high-level.  DSEA&A  is  framed  by  the  hashed 
box.  It  is  driven  from  the  top  by  one  or  more  desired  domain  outcomes.  The  domain  engineer 
represents  the  domain  in  the  domain  architecture.  This  then  serves  to  support  the  domain 
analysis  focused  on  specific  questions  of  interest  derived  from  the  desired  outcomes.  As  part  of 
the  analysis,  the  domain  engineer  identifies  and  assesses  various  alternative  Courses  of  Action 
(COAs)7  to  support  decision-making8  related  to  achieving  the  desired  outcomes. 


7  A  COA  is  a  sequence  of  steps  for  effecting  a  change  in  the  state  of  the  domain  -  or,  stated  another  way,  for  achieving  a  desired 
outcome. 

8  Typical  decisions  include:  accept  a  COA  as  defined,  request  additional  work  to  refine  a  specified  COA,  reject  all  COAs  and 
start  over. 
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2.3  Who  does  DSEA&A? 


DSEA&A  requires  an  explicit  focus  on  the  domain  in  question.  The  domain  is  typically  not 
directly  associated  with  only  a  single  program.  In  this  case  engineering  resources  are  required  to 
span  more  than  one  program.  Funding  for  such  resources  might  come  from  various  sources  -  but 
that  issue  is  not  addressed  here. 

We  will  use  the  term  domain  engineer  to  indicate  someone  who  performs  DSEA&A.  This  will, 
by  definition,  include  architects  and  analysts  working  at  the  domain-level.  These  individuals 
will,  of  necessity,  often  interact  with  counterparts  working  at  the  level  of  individual  programs 
that  relate  to  the  domain.  Some  of  these  individuals  may  simultaneously  have  both  domain  and 
program-level  engineering  responsibilities  (i.e.,  be  dual-hatted). 

Domain  engineers  interact,  as  appropriate,  with  counterparts  in  various  fields:  contracting, 
finance,  procurement,  legal,  logistics,  etc. 

2.4  Why  should  I  do  DSEA&A? 

First  and  foremost,  you  should  do  DSEA&A  because  there  is  desire  to  achieve  some  outcome(s) 
associated  with  a  defined  domain.  Take  a  domain  defined  around  some  operational  concept  such 
as  planning  missions  or  obtaining  intelligence.  Such  domains  are  typically  supported  by  materiel 
acquired  by  more  than  one  acquisition  program  -  and  that  materiel  needs  to  work  together 
efficiently  and  effectively  to  help  realize  desired  mission  effectiveness.  The  outcome  may  be 
explicitly  focused  on  achieving  affordable  support  for  domain  operations.  (The  concept  of 
Affordability,  Efficiency  and  Effectiveness  (AE&E)  is  described  in  Appendix  D.)  Specific 
outcomes  in  such  a  case  might  entail  resolving  some  issue,  mitigating  some  risk,  and/or 
leveraging  some  opportunity.  The  outcome  reflects  stakeholders’  values  and  serves  as  a  means 
for  defining  and  measuring  the  success  of  the  DSEA&A  effort. 

The  domain  engineer  supports  a  decision  (action)  by  one  or  more  stakeholders  related  to 
realizing  the  outcome.  This  could  include  decisions  related  to  requirements  (JCIDS  [1]), 
program  planning  and  budgeting  (PPBE  [2]),  acquisition  (DAS  [3]),  and  Portfolio  Management 
(PfM).  These  decisions  might  include  changes  to  how  existing  programs  execute,  changes  to 
plans  for  future  programs  (e.g.,  strategic  plans,  POMs),  changes  to  system-related  operating 
procedures,  etc. 

DSEA&A  strives  to  ensure  that  these  decisions  are  based  on  high  quality  (rigorously  developed, 
defensible)  analytic  results. 

2.5  What  is  a  “DSEA&A  Sprint?” 

DSEA&A  is  often  amenable  to  execution  in  a  somewhat  agile  fashion  [7]  via  short  iterative 
increments  known  as  “sprints.”  A  DSEA&A  sprint  nominally  takes  on  the  order  of  3  to  6 
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months.9  Every  sprint  should  result  in  some  measurable  progress  towards  achieving  the  stated 
outcome,  but  precise  sprint  contents  depend  on  the  given  context. 

In  some  cases,  a  sequence  of  sprints  might  be  warranted.  Initial  sprints  might  focus  on  setting  up 
the  overall  effort.  Subsequent  sprints  might  focus  on  understanding  the  domain  (developing  the 
initial  domain  architecture),  performing  specific  analysis  against  that  architecture,  and  refining 
the  architecture  in  response  to  the  analysis.  A  sequence  of  sprints  is  generally  shaped  by 
intervening  heading  checks  between  each  sprint. 

2.6  How  are  Sprints  Governed  and  Managed? 


Political, 


Domain 

Knowledge 


DAWG  =  Domain  Analytics  Working  Group 


Figure  2  -  DSEA&A  Management  Process 

Sprints  can  be  overseen  and  managed  in  a  number  of  ways.  Figure  2  shows  a  notional  approach 
that  can  be  adapted  as  needed.  This  particular  approach  includes  a  central  management  body  - 
the  Domain  Analytics  Working  Group  (DAWG)10-  that  manages  the  use  of  shared  resources  and 
promotes  cross-domain  coordination  where  appropriate.  Sprints  that  are  wholly  contained  within 


9  For  IT-heavy  domains.  Other  domains  might  have  different  nominal  sprint  durations. 

10  The  DAWG  concept  was  implemented  as  part  of  the  AF  LCMC  Hanscom-OL  experience  in  DSEA&A. 
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a  single  domain  and/or  that  do  not  use  shared  resources  may  be  managed  within  the  domain  in  a 
similar  fashion  (but  at  a  smaller  scale). 

The  process  starts  with  the  identification  and  prioritization  of  domain  outcomes  by  each  domain. 
This  activity  is  generally  overseen  by  the  domain  authority  and  results  in  a  set  of  potential 
sprints. 

The  DAWG  then  vets  potential  sprints  using  a  set  of  selection  criteria.  This  might  include, 
among  others,  the  timeframe  for  the  expected  impact,  the  number  of  resources  required,  the 
availability  of  resources,  the  breadth  of  the  impact,  and  the  anticipated  value  of  the  result. 

After  a  sprint  is  approved,  the  sprint  team  is  formed  and  executes  the  sprints,  as  described  below. 
This  includes  the  identification  and  characterization  of  COAs,  potentially  iterative  refinement  of 
those  COAs  with  the  stakeholders  and  the  DAWG,  and  assessment  of  the  COAs  against  a  set  of 
assessment  criteria  coordinated  with  the  stakeholders.  The  sprint  ends  based  on  an  evaluation 
against  a  set  of  exit  criteria  that  is  also  coordinated  with  the  stakeholders.11 

In  addition  to  the  above,  the  DAWG  collects  and  shares  lessons  learned  from  across  the  sprints. 

2.7  What  are  Some  Examples  of  Sprints? 

Here  are  some  example  sprints  to  consider: 

Mission  Planning  for  Network-Enabled  Weapons  (NEWs) 

The  introduction  of  Net-Enabled  Weapons  (NEWs)  into  the  Air  Force’s  arsenal  provides 
additional  capability  but  also  requires  additional  C2  (tasking  and  detailed  planning)  effort.  Net- 
Enabled  Weapons,  such  as  the  Joint  Standoff  Weapon  (JSOW)  and  Small  Diameter  Bomb  II 
(SDB  II),  offer  the  potential  to  connect  to  tactical  data  links  (TDLs)  while  inflight  to  support 
dynamic  re-targeting  and  improved  Battle  Damage  Assessment  (BDA)  (among  others).  This 
ongoing  (as  of  this  writing)  sprint  explores  how  to  best  support  the  tasking  and  planning  of  air 
missions  involving  NEWs.  Areas  of  investigation  include  systems  that  support  the  Air 
Operations  Center  (AOC),  systems  that  support  unit-level  mission  planning,  related  data 
standards  such  as  USMTF  and  the  Air  Operations  Community  of  Interest  schema,  and 
mechanisms  to  support  the  exchange  of  data  between  the  AOC  and  the  unit-level.  Current  plans 
related  to  these  areas  may  not  adequately  support  machine-to-machine  data  exchange  among 
these  systems  before  the  widespread  deployment  of  NEWs  in  the  AF  arsenal.  As  a  result,  the 
tasking  and  planning  of  NEW-related  air  missions  may  require  significant  manual  intervention 
with  potential  for  delays  and  data  entry  errors. 

Ubiquitous  Battle  Management  Command  &  Control  (pBMC2) 

Historically,  unique  Battle  Management  Command  &  Control  (BMC2)  solutions  have  been 
developed  for  individual  sensors  often  without  sufficient  consideration  for  the  reuse/sharing  of 
common  components  or  the  need  for  interoperability  among  the  different  sensor  systems.  This 


11  Typical  exit  criteria  might  include  when  an  acceptable  COA  is  defined  and/or  when  DSEA&A  resources  are  depleted. 
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sprint  was  an  investigation  to  determine  whether  coupling  a  BMC2  capability  for  new  sensors 
would  yield  benefits  from  the  perspective  of  AE&E.  Specifically,  it  investigated  the  BMC2 
needs  of  Global  Hawk  Block  40,  Dismount  Detection  Radar  (DDR),  and  the  next  generation 
JSTARS  in  order  to  recommend  approaches  for  solving  their  BMC2  needs.  The  goals  of  this 
work  were  to:  1)  define  and  embrace  a  forward-looking  battle  management  approach  that 
removes  boundaries  from  current  operations,  2)  determine  the  value  in  coupling  traditionally 
separate  BMC2  systems,  and  3)  improve  future  BMC2  delivered  capabilities.  The  sprint 
identified  several  findings  and  made  recommendations  related  to  the  processing  and  distribution 
of  sensor  data  as  well  as  other  systemic  issues  associated  with  realizing  a  pBMC2  capability. 
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3  How  do  I  do  DSEA&A? 


There  are  many  ways  to  do  DSEA&A  but  there  are  some  general  steps  to  perform  and  an 
approximate  order  to  those  steps.  Steps  can  overlap  and  be  revisited  as  additional  information 
is  obtained  or  as  change  occurs  over  time. 

Figure  2  shows  the  overall  approach  to  DSEA&A.  The  need  for  a  DSEA&A  sprint  is 
determined  by  a  set  of  stakeholders12  who  together  have  a  common  interest  in  achieving  some 
desired  outcome(s)  associated  with  the  domain.  The  domain  engineer  works  with  these 
stakeholders  to  define  the  domain,  the  desired  outcome(s),  associated  assessment  criteria 
(measures  of  success),  and  the  technical  scope  of  the  DSEA&A  effort.  The  domain  engineer 
then  architects  and  analyzes  the  domain  to  identify  options  and  assess  them  against  the 
assessment  criteria  leading  to  various  COAs  for  the  stakeholders  to  consider.  The  stakeholders 
subsequently  make  decisions  to:  1)  do  additional  DSEA&A,  2)  follow  a  selected  COA  to  effect 
the  desired  outcome,  or  3)  otherwise  end  the  DSEA&A  effort. 
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Figure  3  -  Domain  Systems  Engineering,  Architecture,  &  Analysis 


12  Not  all  stakeholders  have  an  equal  stake  in  the  success  of  the  DSEA&A  effort.  For  example,  there  may  be  a  small  set  of 
stakeholders  who  provide  significant  resources  for  the  effort  and  who  may  be  considered  as  “customers”  of  the  effort.  In  some 
cases,  there  may  be  a  single  customer. 
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DSEA&A  includes  the  following  steps: 

1.  Setup  the  effort 

2.  Develop  the  Architecture/Model 

3.  Perform  the  Analysis 

4.  Identify  and  document  COAs 

5.  Manage  &  evolve  the  effort 

We  will  discuss  each  of  these  steps  in  turn,  but  some  general  orientation  up  front  is  useful.  Step 
1  defines  and  scopes  the  overall  DSEA&A  effort.  Steps  (2)  and  (3)  are  where  the  bulk  of  the 
heavy  lifting  occurs.  Step  (4)  is  the  critical  clean-up  effort  that  transforms  the  heavy  lifting  into 
something  actionable.  Step  (5)  simply  acknowledges  that  DSEA&A  is  iterative  and  continues 
until  such  time  as  someone  in  authority  decides  to  stop. 

3.1  Step  1  -  Setup  the  Effort 

It’s  critical  to  get  off  on  the  right  foot,  and  this  starts  with  establishing  the  sprint  team, 
identifying  the  stakeholders,  characterizing  the  domain,  defining  the  right  problem  to  address, 
identifying  assessment  and  exit  criteria,  and  scoping  the  DSEA&A  activities.  Note  that  these 
steps  are  not  strictly  sequential.  In  addition,  they  iterate  -  with  feedback  informing  subsequent 
iterations.  For  example,  the  sprint  team  may  evolve  over  time  as  the  understanding  of  the 
domain  evolves  and  the  need  for  certain  skills  becomes  evident.  The  sprint  team  elicits  from 
the  key  stakeholders  the  kinds  of  decisions  needed  to  achieve  the  outcome.  The  team  typically 
documents  the  results  of  this  step  in  a  Terms  of  Reference  (ToR)  to  be  signed  by  key 
stakeholders.  See  Appendix  F  for  a  description  of  typical  ToR  contents. 

Establish  the  Sprint  Team:  The  sprint  team  will  consist  of  appropriate  personnel  from 
(potentially)  a  variety  of  disciplines  to  include  engineering,  finance,  program  management,  and 
contracting  (among  others).  The  team  should  include  government,  FFRDC,  and  contractor 
support  personnel.  Government  advocacy  and  active  participation  is  important.  A  single 
individual  should  be  identified  as  the  sprint  leader.  Train  the  team  members  as  needed  in: 

1 .  The  nature  of  the  domain 

2.  The  scope  of  the  sprint 

3.  DSEA&A  basics 

Once  the  sprint  is  concluded,  the  sprint  team  might  form  the  core  of  a  more  long-lived  (but 
possibly  part-time)  domain  focus  group. 

Identify  the  stakeholders:  (This  is  done  in  concert  with  defining  the  domain.)  A  domain  can 
have  a  wide  range  of  stakeholders  depending  on  the  nature  of  the  problem(s)  being  considered. 
As  the  precise  problem  being  considered  may  not  be  known  or  well-understood  early  on,  it  is 
generally  appropriate  to  cast  a  wide  net  initially  and  then  scope  down  the  list  of  stakeholders  as 
matters  become  more  concrete.  Eventually,  the  domain  engineer  wants  to  focus  on  those  key 
stakeholders  with  whom  he/she  plans  to  engage.  Typical  stakeholders  include  the  domain 
authority,  users/operators,  administrators,  maintainers,  developers,  planners,  budget  sources, 
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acquirers,  testers,  trainers,  sustainers,  researchers,  etc.  as  well  as  any  other  decision-makers 
associated  with  the  sprint.  Eventually  the  domain  engineer  will  engage  with  the  stakeholders  to 
identify  the  stakeholders’  needs  or  equities  relative  to  the  domain.  See  Appendix  G  for  a 
discussion  of  metrics  related  to  stakeholder  engagement. 

As  the  problem  gets  defined  and  the  DSEA&A  effort  gets  scoped,  the  domain  engineer  should 
be  thinking  about  specific  stakeholder  decisions  needed  to  realize  the  outcome.  This  could 
include  strategic  investment  decisions,  specific  programming  decisions,  contractor  engineering 
decisions,  etc.  Be  sure  to  understand  the  nature  of  such  decisions  and  the  role  they  play  in 
realizing  the  outcome.  Eventually  the  domain  engineer  will  develop  COAs  and  assessment 
criteria  that  allow  him/her  to  determine  the  relative  merits/drawbacks  of  each  CO  A  in  an 
unbiased,  consistent  and  defensible  manner.13 

Characterize  the  domain:  As  stated  above,  a  specific  domain  is  a  partitioning  of  an  overall 
problem  space.  It  can  be  defined  based  on  mission  characteristics,  technical  characteristics, 
political  characteristics,  etc.  While  it  may  not  be  feasible  to  precisely  define  the  domain,  it  is 
very  useful  to  have  at  least  a  working  characterization  to  ensure  that  the  domain  engineers 
focus  their  effort  on  relevant  entities.  Don’t  assume  that  such  labels  as  ‘C2,’  ‘ISR,’  ‘cyber,’ 
and  ‘sensors’  are  precisely  understood  concepts.  Provide  additional  modifiers  and  descriptors 
to  add  clarity.  Provide  definitions  of  key  terms  as  needed.  Identify  parent  and  child  domains 
where  relevant.  Consider  the  span  of  control  of  the  decision  maker. 

Define  the  desired  outcome:  Develop  a  statement  of  the  desired  outcome  (a  desired  change 
from  the  current  state  of  the  domain)  based  on  an  understanding  of  the  domain,  the  associated 
stakeholders,  and  the  stakeholders’  needs/interests/equities  (by  performing  a  stakeholder 
analysis  [4]). 

When  formulating  the  desired  outcome: 

•  Consider  the  feasibility  of  achieving  the  outcome  (either  wholly  or  partially).  Avoid 
over-reaching  for  “world  hunger”  types  of  outcomes  but  don’t  focus  on  trivial  ones 
either.  While  guided  by  things  like  Vision  statements,  a  good  desired  outcome  should 
be  more  tangible  (e.g.,  to  make  some  specified  progress  in  realizing  a  particular  military 
capability). 

•  Look  for  outcomes  that  are  domain-level  in  nature.  Avoid  outcomes  that  are  broader 
(“enterprise”  level)  or  narrower  (e.g.,  specific  to  a  given  program). 

•  Identify  the  timeframe  in  which  the  outcome  should  be  realized.  Some  decisions  may 
impact  current  year  funding,  while  others  may  impact  long  term  budget  planning. 
Ideally,  you  should  be  able  to  make  some  defined  progress  towards  the  outcome  within 
a  couple  of  years. 

•  The  outcome  should  be  owned  by  the  key  stakeholders.  Engage  with  key  stakeholders 
to  get  concurrence  on  the  statement  of  the  desired  outcome. 


13  Identification  of  COAs  might  be  deferred  to  a  follow-on  activity  based  on  the  analytic  results  and  available  resources. 
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Remember  that  the  understanding  of  the  domain  will  likely  evolve  over  time;  however,  it  is 
important  to  converge  on  a  “good  enough”  statement  of  the  desired  outcome  early  on  to  avoid 
pursing  dead  ends  wherever  possible.  The  outcome,  after  all,  drives  the  rest  of  the  DSEA&A 
effort.  It  specifically  leads  to  questions  to  be  answered  by  the  analysis. 

Develop  assessment  criteria:  As  part  of  defining  the  outcome(s),  develop  an  understanding  of 
how  progress  towards  achieving  the  outcome  will  be  assessed.  The  assessment  criteria  are 
used  to  gauge  how  a  particular  solution  rates  in  the  broad  categories  of  Affordability, 

Efficiency  and  Effectiveness.  Each  category  should  have  a  list  of  more  specific  criteria  that 
make  up  the  assessment.  For  example,  Effectiveness  might  call  out  that  some  or  all  operational 
requirements  are  met  or  that  there  is  no  loss  of  mission  effectiveness  as  defined  by  the  existing 
capability  currently  in  operation. 

Identify  exit  criteria:  The  exit  criteria  are  used  to  define  what  would  constitute  “as-planned” 
completion  of  the  sprint  effort.  This  could  be,  for  example,  any  or  all  of  the  following: 

•  The  outcome(s)  has  been  achieved. 

•  Decisions  needed  to  achieve  the  outcome(s)  have  been  made. 

•  Sprint  products/artifacts  have  been  delivered  and  approved. 

•  A  pre-specified  level  of  effort  limit  has  been  reached. 

Specific  exit  criteria  should  be  tailored  to  the  domain,  the  outcome(s),  supporting  products,  and 
the  set  of  stakeholders. 

Scope  the  DSEA&A  Activities:  The  problem/outcome  statement  leads  to  the  identification  of 
specific  questions  to  be  addressed  by  the  DSEA&A  effort,  e.g.: 

•  “What  is  the  needed  capability?” 

•  “What  are  the  current  capability  gaps?” 

•  “How  many  of  what  kinds  of  systems  could  provide  the  needed  utility?” 

•  “Is  the  needed  capability  affordable?” 

•  “How  should  we  engineer  those  systems  (to  best  effect)?” 

•  “How  should  we  deploy  and  use  those  systems  (to  best  effect)?” 

•  “How  well  will  some  particular  system  configuration  perform?” 

DSEA&A  emphasizes  the  use  of  appropriate  engineering  rigor.  “Engineering  rigor”  implies 
the  use  of  a  deliberate  and  repeatable  analytic  methodology  against  a  set  of  data  (the  model  or 
architecture).  “Appropriate”  engineering  rigor  is  that  degree  of  rigor  that  provides  “good 
enough”  answers  to  the  questions.  Evolve  the  ToR  as  needed.  Identify  specific  architecture 
and  analysis  tasks.  Define  the  kind  of  data  that  is  needed  to  support  the  stakeholder  decisions. 
Identify  relevant  engineering  artifacts  (e.g.,  the  domain  architecture,  analytic  results).  Decide 
what  level  of  detail  is  needed  to  provide  the  appropriate  rigor  (in  other  words,  right-size  the 
architecture  (breadth  and  depth)  and  the  analysis  (type,  level  of  effort)).  Identify  specific 
progress  metrics.  Remember  the  old  adage,  “Better  is  the  enemy  of  good  enough.” 
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3.2  Step  2  -  Develop  the  Architecture/Model 


The  domain  architecture  is  a  representation  (model)  of  the  salient  aspects  of  the  domain. 
(Hereafter,  the  term  ‘architecture’  is  used  to  also  mean  ‘model.’)  The  salient  aspects  are  those 
that  are  needed  to  support  the  planned  analysis  that  will  in  turn  support  the  identified  stakeholder 
decisions.  The  domain  architecture  should  have  only  as  much  detail  as  is  needed  to  support  the 
analysis. 

Of  note,  the  domain  architecture  is  not  the  sum  of  the  relevant  lower-level  architectures  but  is 
rather  an  abstraction  of  them  that  highlights  only  those  characteristics  that  are  central  to  the 
DSEA&A  effort.  The  architecture  generally  reflects  those  aspects  of  the  domain  that  are 
pertinent  to  the  use  of  the  architecture  (in  this  case,  to  support  analysis  related  to  the  desired 
outcome).  This  could  include  various  (and  selected)  DOTMLPF14  aspects. 

The  architecture  generally  represents  multiple  timeframes  to  include  the  ‘as-is,’  the  ‘as-planned’ 
(to-be),  and  (potentially)  multiple  alternative  ‘could-be’  states.15  (These  alternatives  generally 
line  up  with  the  COAs  that  get  identified  and  assessed  as  a  result  of  the  analysis.)  Optionally,  it 
can  include  an  ‘ultimately  desired’  future  state  (a  target).  Each  such  “version”  of  the  architecture 
should  be  relatively  simple  and  oriented  to  the  desired  outcome(s).  Different  versions  can  be 
expressed  by  highlighting  the  (planned,  proposed,  potential)  changes  in  the  architecture  over 
time  (e.g.,  versions  of  systems,  new  systems,  and  interface  mechanisms). 

Use  appropriate  data  mining  of  stakeholder  needs,  interviews,  surveys,  observations,  etc.  to 
collect  and  structure  relevant  architectural  data  (data  about  salient  aspects  of  the  domain).  Use 
various  modeling  or  architecture  tools  to  store,  process,  and  visualize  that  data.  For  DoD  efforts, 
DoDAF  [5]  provides  a  framework  for  representing  and  visualizing  architectural  data.  Use  of 
DoDAF  tools  may  be  helpful,  but  the  sprint  team  must  determine  the  appropriate  architecture 
artifacts  to  develop  and  how  to  develop  them. 

Evolve  the  architecture  over  time  as  insight  is  gained  into  the  domain  as  a  result  of  analysis  and 
other  investigations. 

Be  sure  to  have  appropriate  domain  stakeholders  validate  the  architecture. 

3.3  Step  3  -  Perform  the  Analysis 

In  DSEA&A,  analysis  is  a  deliberate  effort  to  answer  key  questions  in  support  of  the  decisions  of 
the  key  stakeholders.  The  analysis  leads  to  an  improved  understanding  of  the  domain’s  problem 
space  and  solution  space.  The  analysis  can  also  uncover  additional  questions  related  to  newly 
discovered  issues,  risks,  and  opportunities  while  seeking  to  address  earlier  questions.  A  major 
goal  of  the  analysis  step  is  to  converge  on  an  enhanced  understanding  of  the  feasibility  and  utility 
of  various  alternatives  for  realizing  the  desired  outcome. 

To  perform  analysis: 


14  Doctrine,  Organization,  Training,  Materiel,  Leadership  and  education,  Personnel,  and  Facilities 

15  This  can  be  viewed  as  multiple  versions  of  the  domain  architecture  each  representing  a  single  timeframe  or  chosen  alternative. 
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1)  Review  the  assessment  criteria 

2)  Assess  (challenge/critique)  alternative  future  domain  states  against  those  criteria 
a)  Identify  issues,  risks,  and  opportunities  associated  with  those  states 

3)  Document  the  analysis  results 

Define  the  basis,  or  “perspective,”  of  each  analysis  -  generally  oriented  to  the  desired  outcome 
and  assessment  criteria  in  some  way.  The  perspective  tends  to  shape  the  types  of  findings 
produced  by  the  analysis.  The  perspective(s)  include  such  things  as  AE&E,  technology  maturity, 
conformance  to  standards,  and  even  schedule  alignment. 

There  are  many  types  of  analytical  approaches  to  include  “back  of  the  envelope”  calculations, 
simulations,  optimization  approaches,  prototyping,  and  heuristic  algorithms.  There  are  many 
variations  in  each  of  these  classes  (e.g.,  simple  computation,  discrete-event  simulation,  linear 
programming,  and  genetic  algorithms).  Some  analyses  seek  to  find  optimal  solutions  while 
others  seek  feasible  (good  enough)  solutions.  Some  analyses  are  static  while  others  look  at 
various  conditions  over  time. 

Once  completed,  document  the  findings  and  associated  recommendations  to  support  subsequent 
stakeholder  decision-making.  Appendix  E  lists  some  typical  artifacts  for  documenting  sprint 
results. 

Some  things  to  consider  when  performing  the  analysis  include: 

•  Understanding  dependencies  and  other  relationships 

•  Identifying  appropriate  scenarios,  initial  conditions,  etc. 

•  Understanding  the  impacts  of  operational,  system,  and  technological  change 

It  is  important  to  understand  the  pedigree  of  the  analytical  results  -  how  much  confidence  should 
one  ascribe  to  those  results.  Document  the  assumptions  and  constraints  in  the  model  (as  it  is 
instantiated)  as  well  as  the  limitations  of  the  chosen  analytical  approach. 

3.4  Step  4  -  Identify  and  Document  COAs 

Analytical  results  need  to  be  reviewed,  interpreted,  and  then  transformed  into  practical  actions. 
This  is  where  “the  rubber  meets  the  road.”  As  part  of  the  analysis,  the  domain  engineer 
identifies  and  assesses  various  alternative  Courses  of  Action  (COAs)  to  support  decision-making 
related  to  achieving  the  desired  outcomes.  A  COA  is  a  sequence  of  steps  for  effecting  a  change 
in  the  state  of  the  domain  -  or,  stated  another  way,  for  achieving  a  desired  outcome.  COAs  are 
generally  judged  on  the  basis  of  cost,  benefit  (e.g.,  degree  to  which  they  achieve  the  outcome), 
and  overall  risk,  but  there  may  be  other  specific  factors  relevant  to  the  domain. 

COAs  often  cross  the  full  spectrum  of  DOTMLPF  (Doctrine,  Organization,  Training,  Materiel, 
Leadership,  Personnel,  Facilities).  All  functions  should  be  considered  in  the  analysis  for 
completeness.  The  amount  of  detail  in  a  COA  should  be  commensurate  with  the  degree  of  rigor 
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required  for  the  analysis  and  the  level  at  which  the  decision  needs  to  be  made.  Some  examples 
of  COAs  to  be  investigated  are: 

•  Revise  a  business  process 

•  Improve  the  training  of  personnel 

•  Accelerate  the  fielding  of  new  or  updated  materiel 

•  Modernize  a  (set  of)  system(s)  in  a  specified  way  to  improve  an  operational  capability 

•  Implement  a  new  system  or  system  of  systems  architecture 

•  Invest  in  a  particular  technology 

•  Engineer  systems  to  conform  to  some  technical  reference  architecture 

•  Leverage  a  specific  solution  across  multiple  situations 

•  Do  more  DSEA&A  (but  be  careful  to  avoid  “analysis  paralysis”) 

Typical  decisions  resulting  from  the  identification  of  COAs  include: 

•  Pursue  a  specified  COA  as  defined 

•  Request  additional  work  to  refine  a  specified  COA 

•  Reject  all  COAs  as  presented  (and  either  restart  or  terminate  efforts  to  identify  an 
acceptable  COA) 

Figure  4  presents  an  example  of  a  COA  presentation,  including  factors  and  “pros”  and  “cons”  to 
be  weighed  by  the  decision  maker: 


COA  1:  Complete  Block  10.X  Currently  Contracted  Work 

•  COA  Description:  Comoletework  oncurremly  contracted  DO/TDs  and  deliver  "As  is” 

-  Re-use  Block  10.X  hardware,  software  licenses,  and  GFE  items  on  fielded  baseline 

-  I  nstall  and  i  ntegrate  portion  of  developed  s/w  for  workf  low 

PRO’S  CON’S 

-  Schedule  replanning  to  be  done 

^  -  EDelays  IOC  at  first  site  to  1QFY 13 


No  contract  termination  penalties  Continues  expenditure  of  Block  10.X 


COST  <'$70M> 


funds  for  existing  DO.TDs  and  nsk  of 
needing  more  f  und*ig  later  to 
complete  S232M  FYDP) 


CAPABILITY 


Adds  Enhanced  Workflow 
Management  Capability 

Adds  20  additional  workstations 
and  server  hardware  per  site 

Adds  8x  storage  and  throughput 
capacity  beyond  current  baseline 


Fielded  baseline  meets  current 
mission  need  but  has  nsk  associated 
with  accommodating  new  ter  faces 

10.X  basefane  has  outdated 
hardware  in  need  of  refresh  before 
operating 


Figure  4  -  COA  Example 
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3.5  Step  5  -  Manage  and  Evolve  the  Effort 

In  this  “clean-up”  step,  the  key  stakeholders,  in  conjunction  with  the  sprint  team,  look 
introspectively  at  the  DSEA&A  effort  and  decide  on  a  way  forward.  They  review  the  status  of 
the  effort  against  the  previously  defined  exit  criteria.  Doing  more  analysis  may  provide  critical 
information  -  or  it  may  be  overkill.  Identify  changes  that  may  invalidate  a  portion  of  the  work 
done  to  date. 

Maintain  configuration  control  of  any  DSEA&A  artifacts16  created  to  date  and  update  the 
schedule  of  future  DSEA&A  activities  (if  any).  Update  and  document  accumulated  lessons 
learned  at  appropriate  points  during  sprint  execution. 


16  See  Appendix  E  for  a  list  of  typical  DSEA&A  artifacts. 
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4  Summary 

Domain  Systems  Engineering  Architecting  &  Analysis  (DSEA&A)  (aka  “Domain  Analytics”)  is 
an  approach  for  achieving  desired  outcome(s)  that  pertain  to  some  domain  of  interest;  a  domain 
being  a  bounded  part  of  the  problem  space  having  an  identifiable  controlling  individual  or  group 
of  individuals  authorized  to  make  decisions.  DSEA&A  builds  on  traditional  systems  engineering 
and  architecture  and  analysis  methodologies.  It  is  a  viable  means  for  addressing  issues,  risks  and 
opportunities  that  cut  across  multiple  programs  within  or  across  PEO  boundaries.  A  key  feature 
of  DSEA&A  is  the  proactive  engagement  with  appropriate  stakeholders  in  the  domain  to  ensure 
that  appropriate  analysis  forms  the  basis  of  investment  and  engineering  decisions. 

DSEA&A  is  not  a  single  prescriptive  method  of  performing  analysis.  It  is  a  flexible  framework 
accommodating  many  kinds  of  analysis  and  is  often  amenable  to  execution  in  an  agile  fashion 
via  “sprints”. 
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Appendix  C 

Acronyms 

AE&E 

Affordability,  Efficiency,  and  Effectiveness 

C2 

Command  and  Control 

CFLI 

Core  Function  Lead  Integrator 

CFMP 

Core  Function  Master  Plan 

COA 

Course  of  Action 

CONOPS 

Concept  of  Operations 

DAS 

Defense  Acquisition  System 

DoD 

Department  of  Defense 

DoDAF 

Department  of  Defense  Architecture  Framework 

DOTMLPF 

Doctrine,  Organization,  Training,  Materiel,  Leadership  and  education, 
Personnel,  and  Facilities 

DSEA&A 

Domain  Systems  Engineering,  Architecting,  and  Analysis 

ISR 

Intelligence,  Surveillance,  and  Reconnaissance 

JCIDS 

Joint  Capabilities  Integration  and  Development  System 

PfM 

Portfolio  Management 

PPBE 

Planning,  Programming,  Budgeting,  and  Execution 

POM 

Program  Objective  Memorandum 

SE 

Systems  Engineer  or  Systems  Engineering 

SoS 

System  of  Systems 
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Appendix  D  Affordability,  Efficiency,  and  Effectiveness 

“Affordability,  Efficiency,  and  Effectiveness”  refer  to  three  interrelated  concepts  that  are 
informally  defined  as  follows: 

•  Affordability  -  ability  to  fund  desired  investments 

•  Effectiveness  -  the  bang;  ability  to  achieve  an  organization’s  mission 

•  Efficiency  -  measure  of  the  “Bang  for  the  Buck”  or  “unit  benefit  per  dollar” 

Generally,  the  overall  goal  is  to  realize  efficiency  without  sacrificing  effectiveness  unnecessarily 
while  staying  within  the  constraints  of  affordability.  Stated  another  way,  the  total  cost  of  a 
solution  should  not  exceed  some  specified  budget;  the  effectiveness  (utility,  benefit)  of  a  solution 
should  not  be  below  some  minimum;  and  the  ratio  of  effectiveness  to  cost  should  be  at  a 
maximum  within  the  previous  two  constraints.  This  avoids  low-cost,  but  also  low-effectiveness 
solutions  as  well  as  high-cost  solutions  that  don’t  deliver  commensurate  effectiveness  and  may 
exceed  affordability  constraints. 


Cost  ($) 


Figure  5  -  Affordability,  Efficiency,  and  Effectiveness 

There  are  many  ways  to  measure  cost  and  effectiveness.  Note  specifically  that  effectiveness  can 
be  a  combination  of  many  ‘-ilities’  to  include  functionality,  performance,  reliability,  availability, 
security,  etc.  Measures  of  Effectiveness  (MOEs)  are  generally  capability-specific.  They  reflect 
stakeholder  values. 
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Appendix  E  Potential  DSEA&A  Artifacts 


The  following  shows  some  potential  DSEA&A  artifacts.  The  primary  artifacts  are  the  domain 
architecture  and  the  results  of  the  analysis.  This  is  not  intended  to  be  a  complete  list. 

•  Sprint  Terms  of  Reference 

•  Sprint  Plan 

•  Domain/Sub-Domain  (reference)  Architecture  Baseline 

o  Perspective  Overlays  -  Questioning/Challenging 

•  Affordability,  Effectiveness  &  Efficiencies  (AE&E) 

o  Opportunities  Identification 
o  Justification  Analyses 

■  Performance  -  Cost  Drivers  Sensitivity  Analysis 

■  Requirements  Analysis  and  Rationalization 

■  Certification  and  Accreditation  (C&A)  Implications 

■  Vulnerability  Assessments  (MA,  Robustness-Resiliency- Adaptability, 
Composeability,  etc.) 

■  System  of  System  Performance  Models 

■  Integration  and  Interoperability  (I&I)  Constraints/’ Desirements’ 

■  Quick  Reaction  (early)  Capability  (QRC)  Potential 

•  CFMP  Futures  Recommendations  &  CFLI  Support  Obligations/Proposals 

•  Reference  Design/ Architecture  (proposed  direction/details) 

•  Capability  Roadmaps  (dependencies  and  required  efforts  synchronization) 

•  Risk  Assessments,  Engineering  Watchlists 

•  Interface  Definitions  and  Constraints/Opportunities 

•  Relevant  Technology  Assessments 

o  Transition  Opportunities  (Labs,  Industry,  . . .) 
o  Relevant  COTS/MIL  Developments 
o  Critical  Technology  Elements  (CTEs)  Identification 
o  Program  Protection/ Anti-Tamper  considerations 
o  Technology  Readiness  (level)  Assessments  (TRAs) 

•  Standards  Determination  (Open,  COTS,  Mil-unique,  etc.) 

•  Independent  Technical  Assessments  (IT A) 

•  Experimentation/Prototyping/M&S  Recommendations 

•  Supportability  (‘ilities’)  Implications  Assessment 
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Appendix  F  DSEA&A  Sprint  Terms  of  Reference  Typical 
Contents 

•  General  Background  Information 

•  Motivation  for  Conducting  the  Sprint 

•  Sprint  Scope  and  Goals 

•  Sprint  Governance  Structure 

•  Stakeholder/Participant  Roles  and  Responsibilities 

•  Sprint  Method  of  Operation  (e.g..  Ground  rules,  Sprint  Process,  Tools,  Review, 
Reporting) 

•  Relevant  Policies,  Procedures  and  Guidelines 

•  Sprint  Products 

•  Sprint  Schedule 

•  Resources  Required  (at  all  levels  and  from  all  stakeholders) 

•  Sensitivity  of  Information 
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Appendix  G  Stakeholder  Engagement  Metrics 

1 .  Sprint  has  a  Government  customer17 

■  Threshold:  Sprint  scope  (sprint  outcome,  context,  exit  criteria,  stakeholders  ,  and 
sprint  approach/duration)  is  documented  and  approved  by  appropriate 
stakeholders 

2.  Gov’t  provides  an  Engineering  focal  point 

■  Threshold:  A  Government  Engineering  focal  point  is  designated  and  is  available 
(at  least  weekly)  to  guide  effort 

■  Objective:  Government  Engineering  focal  point  is  proactively  engaged  throughout 
the  Sprint  and  enables  stakeholder  involvement,  including  at  least  one  vector- 
check  with  key  stakeholders  during  sprint  and  periodic  management  updates 

3.  Stakeholders  are  appropriately  involved  in  Sprint 

■  Threshold:  Stakeholder  group  includes  at  least  one  (Government)  MAJCOM/User 
representative  and  all  (planned)  stakeholders  (or  designated  representatives) 
participate  in  a  Sprint  kickoff,  providing  opportunity  for  feedback  on  sprint 
execution  approach 

■  Objective:  At  least  the  “key”  stakeholders  (per  approved  sprint  scope)  participate 
continuously  throughout  sprint,  enabling  team  access  to  the  right  guidance, 
information  and  people  at  the  right  times  to  efficiently  execute  the  sprint  and 
develop  planned  products 

4.  Stakeholders  are  provided  the  sprint  results 

■  Threshold:  All  stakeholders  receive  a  sprint  readout  package 

■  Objective:  All  stakeholders  are  briefed  and  provide  feedback  on  sprint  results  and 
implications 

5.  Sprint  results  are  leveraged/applied 

■  Threshold:  By  key  stakeholders 

■  Objective:  (Also)  by  other  relevant  stakeholders 


17  A  customer  is  a  type  of  key  stakeholder  who  provides  resources  for  the  sprint. 


